29 January 1998
Burlington, Mass.--(Business Wire) -- January 28, 1998 -- New research from Ovum, an independent information technology and telecommunications analyst group, urges users to be cautious when looking at developing applications which encompass the Internet. Ovum's report, Middleware and the Internet, concludes that pragmatism must win the day when 'bet-your-business' applications are at stake. According to Ovum, the most frequently used solution -- Web Browser/Web Server and CGI/ISAPI/NSAPI(a) -- is unreliable, slow, insecure and prone to availability problems.
According to Rosemary Rock-Evans, Ovum associate and lead author on the report, "The Internet infrastructure is far from sufficient for supporting business-critical transactions. Many corporations have come to rely on services provided by middleware products which are capable of providing reliability, availability and security to distributed applications. These characteristics are precisely what the Internet network currently lacks. "
According to Middleware and the Internet, middleware provides a set of services that are specifically geared towards supporting distributed computing. These services ensure that any distributed application whether it is built over the Internet or not - is scalable, reliable, gives high performance, is secure and available. Over the Internet, middleware can provide services that:
- ensure a message cannot be read or removed, such as encryption- make messages smaller and faster, such as compression and buffer optimization
- improve the speed connection, such as address caching and optimal address resolution
- increase availability, such as retry connect and automatic fault handling
- synchronize events over the network, such as distributed time services
Rock-Evans adds, "A corporation wanting to develop applications over the Internet has three choices. It can use a 'bare bones' Web Browser/ Web Server solution, treating it as middleware. It can use the Web Browser/ Web Server as the basis for a solution but augment its functionality with additional services provided by middleware vendors. Or it can completely by-pass the Web Browser/Web Server altogether."
"We do not recommend that users take the first option. Web Browser/ Web Server software simply does not provide the scalability, availability, reliability, security or high-performance services needed," concludes Rock-Evans.
Ovum recommends users to pursue one of the following deployment options:
- use an 'application middleware' solution such as SCO or Citrix (but only if the vendor merges its functionality with that of an established middleware vendor)- use push distribution or Internet launcher technology to download the middleware and application (but only if users can develop the client application to be portable)
- when developing applications that require users to pass a security challenge to gain access, send the client-based middleware and application functionality by post, for example, on CD-ROM
- use middleware that has the capability to 'bootstrap' itself at runtime.
About Middleware and the Internet
Middleware and the Internet is a result of nine months intensive research by Ovum. The report describes and compares solutions for building Internet applications using middleware as one part of the overall approach. Authored by Rosemary Rock-Evans and edited by Neil Ward-Dutton, Middleware and the Internet is available immediately from Ovum Inc, and costs $2,775. A free white paper based-on Middleware and the Internet is available from Ovum's web site. Go to http://www.ovum.com/news/mdi/mdiwp.html [Mirrored below]
Also from Ovum, Ovum Evaluates: Middleware, by Rosemary Rock-Evans, $4,625, and Ovum Evaluates: Web Development Tools, by Neil Ward-Dutton, $1,850.
About Ovum
Ovum is an information technology and telecommunications analyst group, providing independent, authoritative information on key market, technical and regulatory developments. Ovum's customer base comprises leading blue-chip organizations including suppliers, users and policy makers worldwide. Ovum has offices in Boston, London and Melbourne and currently employs 130 staff worldwide.
(a) Common Gateway Interface (CGI), Microsoft Information Server API (ISAPI), Netscape Server API (NSAPI)
CONTACT: Ovum Inc. | Dave Hatch, (781) 272-6414 ext.12 | dhh@ovum.com | or | Ovum Inc. | Sarah Lynne Cooper, (781) 272-6414 ext.16 | slc@ovum.com
Source: http://www.ovum.com/news/mdi/mdiwp.html
The Worldwide Web represents a global network which makes all kinds of information available to anyone, anywhere. Businesses are increasingly relying on the Internet and Worldwide Web in order to do business with each other, and with individuals.
However, the level of service offered by Internet infrastructure is far from sufficient for supporting business-critical transactions – for example, passing large amounts of sales or ordering data in real-time between organisations. The Internet was designed to run like a tractor, not like a Saab – like the U.S Postal Service which "always gets through", data sent over the Internet will not be lost: but the network cannot guarantee any particular time or day for delivery, and data can even be returned "addressee unknown".
Many large business have come to rely on services over and above those provided by the basic corporate network, as supplied by middleware products. Middleware can offer Reliability, Availability and Security (RAS) to distributed applications – and RAS characteristics are precisely what the Internet network lacks.
Middleware and the Internet describes and compares solutions for building Internet applications using middleware as one part of the overall approach. The pros and cons of each approach are described, and we provide details of products supporting each approach. The report assesses each approach on whether the result is secure, reliable, will give good performance and be highly available.
Middleware provides a set of services that are specifically geared towards supporting distributed computing. These services ensure that any distributed application – whether it is built over the Internet or not – is scalable, reliable, gives high performance, is secure and available.
Over the Internet, middleware can provide services that:
• ensure a message cannot be read or removed, such as encryption• make messages smaller and faster, such as compression and buffer optimisation
• increase reliability of message content, such as integrity checking
• improve the speed of connection, such as address caching and optimal address resolution
• increase availability, such as retry connect and automatic fault handling
• synchronise events over the network, such as distributed time services.
When a message gets to its destination host machine, the middleware can provide an enormous number of additional services:
• fail-over services, automatic restart and alternative server services to improve availability• authentication and authorisation services, coupled with end-to-end encryption and single sign-on to provide security of access
• load balancing, automatic multi-threading or multi-tasking, dynamic buffer allocation and intelligent message routing to improve performance
• central console-based administration facilities to enable you to monitor the network, monitor, diagnose and correct faults, and monitor the performance of your entire configuration
• guaranteed delivery to ensure a message reaches its destination.
There are undoubtedly some problems with the Internet that middleware cannot solve. It cannot solve the problems of the directory service used for the Internet or the problems of line capacity, or resolve issues with underlying packet security. These are problems being tackled by IPsec, the Internet Service providers and the line providers.
There are six main types of middleware:
• RPCs (remote procedure call)• DCE (distributed computing environment)
• MOM (message-oriented middleware)
• DTPMs (distributed transaction processing middleware)
• ORBs (object request brokers) of which there are three basic types: CORBA ORBs, DCOM and Java RMI
• Database connectivity middleware.
A remote procedure call is a call from a program on one machine to a procedure on another machine (or on the same machine but not in the same program). RPCs are essentially synchronous in nature – the calling program makes the call and blocks processing while waiting for the reply.
RPC middleware is largely tactical in nature. Companies have used it, for example, to train staff in the basics of distributed processing, and in small, low-value applications where a simple, cheap, easy-to-use solution is needed.
DCE (Distributed Computing Environment) is a standard originally developed by the OSF (Open Software Foundation) and is now being enhanced by the Open Group. The standard is not a specification, but is provided by the Open Group as source code. DCE source code is then licensed to companies wanting to sell or provide DCE on their machines.
DCE provides an excellent technical architecture for distributed computing, but it is expensive and complex and requires a high level of commitment from those taking it up. Many companies using DCE employ permanent teams of experienced technical people, whose only role is to provide simplified interfaces and add-on services to the basic core services.
MOM enables a process to communicate with one or more other processes over the network using messages. Messages usually consist of control informationand application data. The control data is used by the messaging software. Application data may be an arbitrarily long sequence of bytes that contains data such as arrays, video images, simple data structures, images or sound.
MOM has a special place in the armoury of a developer. MOM software is not infrastructural software – you would not use it to underpin all your applications. It is not just the unique nature of service support that determines this, the directory services – although protected from loss and likely to give reasonable performance (the file is located on the host and does not need to search the network) – is tedious to set up and an administrative overhead.
The high-profile work of the Object Management Group (OMG) has led to the term ORB being seen as almost synonymous with the OMG's standard for ORBs – CORBA. It is important to realise, however, that there are more ORBs than just the CORBA implementations: the term ORB includes any products that support communication between objects. DTPMs are, in effect, ORBs, because they support object inter-communication. Microsoft's DCOM is also an ORB. What may not be known, however, is that there are yet other non-CORBA ORBs – products such as Newi and RDO.
One of the most confusing aspects about DTPMs is their name. Some people think they are just 'jumped up' TP Monitors; others think they are not middleware at all. In fact, DTPMs are the most highly functional of all the middleware products, providing an extensive array of services. They owe little to TP monitors.
Although DTPMs provide key reliability services (including integrity checking of messages, protection of directory services from loss and distributed transaction control), other reliability services (such as guaranteed delivery) that would slow processing are not provided. This is where MOM products have a special role to play, because the combination of a DTPM with a MOM product (especially MOM products that use queues that are XA-compliant) is a powerful environment for developing applications.
Figures 1 to 6 summarise the functions and services provided by the main types of middleware under the key headings we consider in Middleware and the Internet – that is, Availability, Reliability, Performance, Security, Productivity and Applicability.
Figure 1 Availability
|
RPC |
DCE |
MOM |
ORB |
DTPM |
|
|
Replicated directory |
N |
Y |
N |
N |
Y |
|
Fail-over |
N |
N |
N |
N |
Y |
|
Automatic server restart |
N |
N |
N |
N |
Y |
|
On-line central fault monitoring and diagnosis |
Some |
Some |
Y |
Some |
Y |
|
Retry connection |
Y |
Y |
Y |
Y |
Y |
|
Alternative server |
N |
Y |
N |
N |
Y |
|
Dynamic buffer overflow |
Some |
N |
N |
Some |
Some |
Figure 2 Reliability
|
RPC |
DCE |
MOM |
ORB |
DTPM |
|
|
Replicated directory |
N |
N |
N |
N |
Y |
|
Integrity checking |
Y |
Y |
Y |
Y |
Y |
|
Guaranteed delivery |
N |
N |
Y |
Some |
N |
|
Distributed transaction service |
N |
N |
N |
Some |
Y |
|
Data protection of queues |
N |
N |
Some |
DCOM |
N |
|
Distributed time service |
N |
Y |
N |
N |
N |
Figure 3 High performance
|
RPC |
DCE |
MOM |
ORB |
DTPM |
|
|
Replicated memory-based directory |
N |
N |
N |
N |
Y |
|
Concurrent communication |
Some |
N |
Y |
DCOM |
Y |
|
Asynchronous communication support |
Some |
N |
Y |
Some |
Y |
|
Automatic multi-threading or multi-tasking |
Some |
N |
Some |
Some |
Y |
|
Load balancing |
N |
N |
N |
N |
Y |
|
Data-directed load balancing |
N |
N |
N |
N |
Y |
|
Optimal addressing |
Y |
Y |
Y |
Y |
Y |
|
Message prioritisation |
N |
N |
Y |
N |
Some |
|
Buffer optimisation; for example, compression |
Some |
Y |
Some |
N |
Y |
|
On-line centralised performance monitoring |
Some |
Some |
Y |
DCOM |
Y |
Figure 4 Security
|
RPC |
DCE |
ORB |
MOM |
DTPM |
|
|
Authentication |
N |
Y |
Some |
Some |
Y |
|
Authorisation |
N |
Y |
Some |
Some |
Y |
|
Encryption |
N |
Y |
Some |
N |
Most |
Figure 5 Productivity
|
RPC |
DCE |
MOM |
ORB |
DTPM |
|
|
Data format translation |
Y |
Y |
Some |
Y |
Y |
|
Transparent buffer handling |
Y |
Y |
Y |
Y |
Y |
|
Self registration of server in directory |
N |
Y/N |
N |
N |
Y |
|
Automatic memory management |
Y |
N |
Y |
N |
Y |
|
Automatic fault handling |
Y |
Y |
Y |
N |
Y |
|
No network programming |
Y |
Y |
Y |
Y |
Y |
|
Context bridging |
N |
N |
Y |
N |
Y |
|
Multiple third-party tool support |
Some |
N |
Y |
DCOM (some) |
Y |
|
Minimal command set |
Y |
N (600) |
Y |
N |
Y |
|
Automatic session handling |
Y |
Y |
Y |
Y |
Y |
Figure 6 Applicability
|
RPC |
DCE |
MOM |
ORB |
DTPM |
|
|
Unlimited message length |
Y |
Y |
Some |
Y |
Y |
|
No restriction of message content |
N |
N |
Y |
N |
Y |
|
Multiple programming paradigms (eg object, functions, and messages) |
N |
N |
N |
N |
Y |
|
Multiple distribution options (to queue, application and memory) |
N |
N |
Y |
Y |
Y |
|
Multiple communication options (multi-cast, request/reply, one-way and conversational) |
N |
N |
Some |
Y (not conv) |
Most Y |
|
Deferred delivery |
N |
N |
Y |
DCOM |
Y |
|
Message pull/poll |
N |
N |
Y |
Y |
Y |
|
Triggering |
N |
N |
Some |
Y |
Some |
Is web browser/web server software really middleware? The answer is no. But it is now being asked to fulfil that role – connecting process to process.
When viewed as middleware, service support is poor – any application based on 'bare bones' web technology is not going to be scalable, reliable, high performance, available or secure.
There are additional limitations:
• what service support is provided, is not end-to-end, in that the same technology cannot be used throughout the organisation to provide distributed processing support across the enterprise• the HTTP protocol used for communication is extremely limited
• the processes that can be used at either end of the communication are limited. Not all languages are supported and, in some cases, your programs will be tied into the web server/web browser architecture.
This is a new category of product which is being positioned in the role of middleware. Within this category we include products such as SCO's Tarantella, Citrix's WinFrame and Insignia Solutions' NTrigue.
These products are strong in their support for the front-end middleware functions, but weak in their support for the back-end functions. The service support is also not end-to-end, in that the same technology cannot be used to provide distributed processing support across the enterprise.
A company wanting to develop applications over the Internet has three possible choices:
• it can use a 'bare bones' web browser/web server solution, treating it as middleware. In this case the developer uses CGI programs or NSAPI/ISAPI programs on the server host to provide the functionality. Some additional client-side functionality can be built in with scriptlets, Java applets, ActiveX controls or plug-ins• it can use the web browser/web server as the basis for a solution (using the GUI capabilities of the browser and the ability to launch applets via a page), but augment its functionality with additional services provided by middleware vendors
• it can completely by-pass the web browser/web server and provide middleware that replaces the web browser and web server altogether.
We do not recommend the use of the first option, because web browser/web server software simply does not provide the scalability, availability, reliability, security or high performance services needed.
In this solution, the browser interface is used to support the application, but the web browser is supplemented by services provided by the middleware. The HTTP protocol is not used, but is replaced by a purpose-built protocol; the web server is by-passed – communication is direct to the middleware on the remote server. There are two solutions supported by middleware vendors: the middleware is pre-loaded or down-loaded.
In this solution, the middleware is pre-loaded on the client machine before the execution of the application takes place. This solution may be supported by browser plug-ins; a partnership between a middleware and browser vendor to embed the middleware in the browser (the option provided by Netscape and Borland/Visigenic); or by offering services as part of the operating system (the option provided by Microsoft with DCOM).
Of these options, the plug-in approach is the most reasonable option – as long as the vendor is able to provide enough variants to cope with all browsers.
Of the solutions on the market, only Citrix supports plug-ins. Application brokers (of which Citrix WinFrame is one) do not support the sort of functionality needed for Internet-based use; but if Citrix, for example, was to merge its functionality with that of an established middleware vendor, the solution would be an extremely attractive one. An application broker merged with a DTPM, for example, would be a sure-fire winner.
In this solution, the middleware functionality is down-loaded to the browser as a Java applet (or similar) at runtime. Once down-loaded, it by-passes the web browser and web server and sets up its own communication link using its own protocol, with middleware on the host. The web browser is only used for display purposes.
With this type of middleware deployment solution, the application itself may remain remote, or it may be downloaded along with the middleware (in which case, the application may be downloaded each time it is invoked, or it may be cached).
Keeping the application remote is an attractive option, because it minimises download time. Downloading the application may also be feasible, provided:
• middleware vendors are able to handle the divergence in browsers and JVMs• application developers write their applications to only use core browser and JVM technology, or middleware vendors provide developers with software to smooth out the differences
• middleware vendors do not sacrifice functionality for small size
• application and middleware services can be kept small, or are compressed
• the security mechanisms of Java applets are not relaxed.
In this case, the application and middleware are placed on the client machine (they may be downloaded or pre-loaded) and communicate directly with middleware on the host server machine. No web server or web browser is used. Where the application and middleware are pre-loaded, the user can be sent the software as a package (on a CD ROM, for example). Where the application and middleware are down-loaded, push distribution technology or Internet launchers can be used.
The advantage of such a solution is that the full functionality of both middleware and application can be used on client and server. The application can be developed to be secure, reliable, available, of high performance and scalable. The major disadvantages are that the client application has to be written to be portable across a number of machines (to avoid the problem of versions), and access to your application will be limited to known users.
We believe that this solution should be considered by companies, however, before they rush to develop Java applet-based applications running under a web browser. In the long run, this solution has a good chance of offering superior functionality.
We recommend that you pursue one of the following deployment options:
• use an application broker, but only if the vendor merges its functionality with that of an established middleware vendor• use push distribution or Internet launcher technology to download the middleware and application to the user, but only if you can develop the client application to be portable (tools can be used here). We cover three vendors here – OSA, Marimba and Novadigm – but established SMS vendors are also starting to provide this technology
• post the software – in other words, send the middleware and application functionality by post, for example, on CD ROM. Use this when you are developing applications needing a check of the users' credentials before you provide access
• use downloaded middleware – in other words, middleware that has the capability to support the download of itself at runtime (subject to the caveats outlined in section A4.1 Work with Web browser/Web server).
Application broker vendors such as SCO, Citrix and Insignia Solutions should merge their functionality with that of an established middleware vendor – DTPMs are a prime candidate here.
Providers of object, transaction, messaging and database connectivity middleware products should:
• consider merging their functionality with that of the application broker vendors• add functionality that handles the divergence in browsers and JVMs
• provide developers with software to smooth out the differences between JVMs and browsers
• consider the use of push distribution software and Internet launchers as an additional option to applet down-load
• ensure the middleware downloaded to the client is fully functional, but provide ways of compressing the applet and middleware on down-load (for example, a decompression applet is downloaded first)
• rigorously push to have the Java applet sandbox retained by browser vendors.
This white paper is Copyright © Ovum, Ltd. 1997 - all
rights reserved.
You are hereby licenced to: use this white paper for your own research purposes;
make as many copies of this white paper as you wish; give exact copies of
this white paper to anyone; and distribute this white paper in its unmodified
form via electronic means. There is no charge for any of the above.
You are specifically prohibited from charging, or requesting donations, for
any such copies, however made; and any copies made must incorporate this
Copyright notice and Licence agreement statement in full and without
alteration.